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REMARKS 

In view of the following discussion, the Applicants submit that none of the claims 
now pending in the application is indefinite under the provisions of 35 U.S.C. §112 or 
obvious under the provisions of 35 U.S.C. §103. Thus, the Applicants believe that all of 
these claims are in allowable form. 

1. REJECTION OF CLAIMS 1. 2. 7. 8. 13. 14. 20. 21. 24. 25. 26. AND 29 UNDER 35 
U.S.C. S 112 

Claims 1, 2, 7, 8, 13, 14, 20, 21, 24, 25, 28, and 29 stand rejected under 35 
U.S.C. § 112, second paragraph as being indefinite. In response, the Applicants have 
amended claims 1, 7, 13, 20, 24, and 28 in order to more clearly recite aspects of the 
invention. 

Specifically, recitations of "potentially similar features" have been amended to 
recite "similar features." Recitations of a "minimum similarity requirement" have been 
amended to recite a "threshold similarity requirement." In light of these amendments, 
the Applicants respectfully submit that claims 1, 7, 13, 20, 24, and 28 are sufficiently 
definite within the meaning of 35 U.S.C. § 112, second paragraph. 

Claims 2, 8, 14, 21, 25, and 29 depend from claims 1, 7, 13. 20, 24. and 28 and 
recite additional features. As such, and at least for the reasons stated above with 
respect to claims 1, 7, 13, 20, 24, and 28, the Applicants respectfully submit that claims 

2, 8, 14, 21, 25, and 29 are also sufficiently definite within the meaning of 35 U.S.C. § 
112, second paragraph. 

As such, the Applicants respectfully request that the rejection of claims 1 , 2, 7, 8, 
13, 14, 20, 21, 24, 25, 28, and 29 under 35 U.S.C. § 112 be withdrawn. 

II. REJECTI ON OF CLAIMS 1. 2. 7. 8. 13. 14. 20. 21. 24. 25. 28. AND 29 UNDER 35 
U.S.C. 6 103 

Claims 1, 2, 7, 8, 13, 20, 21, 24, 25, 28, and 29 stand rejected as being 
unpatentable over the Nine et al. patent (U.S. 6,560,611, issued May 6, 2003, 
hereinafter "Nine"). The Applicants respectfully traverse the rejection. Specifically, the 
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Applicants submit that Nine fails to teach, show, or suggest several of the features 
recited in Applicants' independent claims 1, 7, 13, 20, 24, and 28. 

Primarily, the Applicants submit that Nine is completely devoid of any teaching, 
showing, or suggestion relating to the comparison of an alert (indicating an attack or 
anomalous incident) - or more specifically, the comparison of features of the alert - to 
the features of existing alert classes, in order to classify the alert , as claimed by the 
Applicants in independent claims 1, 7, 13, 20, 24, and 28. 

By contrast, Nine teaches a network monitoring system that simply reports a 
detected problem to the proper individual (e.g., technician), based on the nature of the 
problem. That is, Nine does not classify the detected problem (e.g., in accordance with 
its features) by comparing it to known problems, but simply evaluates the detected 
problem as a discrete incident and reports it to a human technician for further action. 

Specifically, Nine teaches a remote monitoring system (RMS) that reports to a 
network operation site (NOS) when the RMS detects an anomaly with respect to a 
service it monitors. The report provided by the RMS is a ticket or data record containing 
information about the service (e.g., location, severity of problem, time of occurrence). In 
addition, the system "determines the nature of the problem, and notifies the proper 
personnel [e.g., a technician]" (See, Nine at column 3, lines 25-27). 

For instance, the portion of Nine that the Examiner cites to teach the limitations 
of "updating a threshold similarity expectation for one or more features" of an alert 
relative to features of alert classes and of "updating a similarity expectation for one or 
more features" of an alert relative to features of alert classes in fact merely teaches that 
the monitoring software is replicated for each service on a device by an informer engine 
executing forker software and sender software (See, e.g. Nine at column 5, line 45 - 
column 6, line 9). There is no discussion of examining the features of an alert , or of the 
need to update a threshold similarity requirement or a similarity expectation for the 
features of the alert to the one or more alert classes. 

The portion of Nine that the Examiner cites to teach the limitations of "comparing 
[a] new alert with one or more alert classes" and "associating the new alert with the 
existing alert class that the new alert most closely matches" in fact merely teaches three 
techniques for detecting a problem with a monitored service. The first technique checks 
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to make sure that the service is responsive (e.g., by "ping, nmap, finger, or telnet", Nine 
at column 7, lines 25-33). The second technique monitors environmental sensors to 
detect problems with the environment (e.g., u if the temperature is too high", Nine at 
column 7, lines 34-39). The third technique examines a log of the monitored service 
and parses for potential problems (e.g., indication that a particular route associated with 
a router is not functioning, Nine at column 7, lines 40-46). None of these techniques 
involve the comparison of an alert to existing alert classes , or the association of the alert 
with one of the existing alert classes based on the comparison. 

The portion of Nine that the Examiner cites to teach the limitations of "comparing 
[a] new alert with one or more alert classes" and "defining a new alert class that is 
associated with the new alert" in fact merely teaches that log files for a monitored 
service may be used to diagnose problems with the service. Again, there is no mention 
of the need to compare an alert with existing alert classes in order to classify the alert, 
as claimed by the Applicants. 

Moreover, Nine does not even teach, show, or suggest that an alert may be 
classified in accordance with its features. The portion of Nine that the Examiner cites to 
teach the limitation of "identifying a set of potentially similar features shared by [a] new 
alert and one or more existing alert classes" in actuality merely teaches that software 
monitors a service and reports to the NOS when the service is unresponsive or when an 
anomaly is detected. The report contains "information about the service, such as 
location, severity of the problem, and time of occurrence" (See, e.g., Nine at column 3, 
lines 12-20), There is no mention in this passage of the need to identify features of the 
problem or to compare the problem to other known problems (e.g., existing alert 
classes) based on the identified features. 

In short, as discussed above, Nine fails to teach, show, or suggest any sort of 
classification of alerts by comparing features of the alerts to features of existing alert 
classes , as recited by the Applicants in independent claims 1, 7, 13, 20, 24, and 28. 
The Examiner submits in the Final Office Action, however, that "[i]n parsing the ticket, 
the receiver is taking features of the alert then comparing them to other alerts and 
classifying the alert, which is deciding where to place the pending ticket. In other words 
the pending ticket gets placed with similar pending tickets, which are those in the same 
class. The class is decided by comparing the features of the ticket to features of other 
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tickets" (Final Office Action, Pages 2-3). The Applicants respectfully disagree. 

Specifically, the Applicants respectfully submit that the Examiner is reading far 
more into the disclosure of Nine than Nine actually discloses. The Examiner relies on a 
single, somewhat vague sentence in Nine to support the above reading: "Upon receipt 
of the ticket, receiver process parses the ticket and uses the information in the ticket to 
query accounting engine for information on where to place the ticket" (Nine, column 8, 
lines 38-41). The Applicants note that nowhere in this passage is there any mention of 
tickets other than the received ticket, nor is there mention of any sort of comparison 
involving the received ticket Nine fails to disclose any details as to how the location for 
the received ticket is determined from the parsed information . Certainly, nothing in Nine 
teaches or suggests that this determination is made by comparing the ticket with other 
tickets or classes of tickets. There is simply no mention of a classification step, as 
claimed by the Applicants. 

Specifically, Applicants 1 claims 1, 7, 13, 20, 24, and 28 positively recite: 



1. In an intrusion detection system that includes a plurality of sensors that generate 
alerts when attacks or anomalous incidents are detected, a method for organizing the 
alerts into alert classes, both the alerts and the alert classes having a plurality of 
features, the method comprising the steps of: 

(a) receiving a new alert; 

(b) identifying a set of similar features shared by the new alert and one or more 
existing alert classes : 

(c) updating a threshold similarity requirement for one or more of the similar 
features : 

(d) updating a similarity expectation for one or more of the similar features : 

(e) comparing the new alert with the one or more existing alert classes : and either: 
(f1) associating the new alert with a one of the one or more existing alert classes 

that the new alert most closely matches : or 

(f2) defining a new alert class that is associated with the new alert . (Emphasis 
added) 



7. A computer readable medium containing an executable program for organizing 
alerts that are generated by a plurality of sensors into alert classes, both the alerts and 
the alert classes having a plurality of features, where the program performs the steps of: 

(a) receiving a new alert; 

(b) identifying a set of similar features shared bv the new alert and one or more 
existing alert classes ; 

(c) updating a threshold similarity reouirement for one or more of the similar 
features: 
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(cl) updating a similarity expectation for one or more of the similar features; 

(e) comparing the new alert with the one or more existing alert classes : and either: 

(ft) associating the new alert with a one of the one or more existing alert classes 
that the new alert most closely matches : or 

(f2) defining a new alert class that is associated with the new alert . (Emphasis 
added) 



13. In an intrusion detection system that includes a plurality of sensors that generate 
alerts when attacks or anomalous incidents are detected, a system for organizing the 
alerts into alert classes, both the alerts and the alert classes having a plurality of 
features, where the system comprises: 

(a) means for receiving a new alert; 

(b) means for identifying a set of similar features shared bv the new alert and one or 
more existing alert classes : 

(c) means for updating a threshold similarity reguirement for one or more of the 
similar features ; 

(d) means for updating a similarity expectation for one or more of the similar 
features : 

(e) means for comparing the new alert with the one or more existing alert classes : 
and 

(f1) means for associating the new alert with a one of the one or more existing alert 
classes that the new alert most closely matches, or defining a new alert class that is 
associated with the new alert . (Emphasis added) 

20. A method for organizing alerts into alert classes, both the alerts and the alert 
classes having a plurality of features, each of the plurality of features having one or 
more values, the method comprising the steps of: 

(a) receiving a new alert; 

(b) identifying a set of similar features shared bv the new alert and one or more 
existing alert classes : 

(c) updating a similarity expectation for one or more feature values : 

(d) comparing the new alert with the one or more existing alert classes : and either: 
(e1) associating the new alert with a one of the one or more existing alert classes 

that the new alert most closely matches : or 

(e2) defining a new alert class that is associated with the new alert . (Emphasis 
added) 



24. A computer readable medium containing an executable program for organizing 
alerts into alert classes, both the alerts and the alert classes having a plurality of 
features, each of the plurality of features having one or more values, where the program 
performs the steps of: 

(a) receiving a new alert; 

(b) identifying a set of similar features shared bv the new alert and one or more 
existing alert classes : 
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(c) updating a similarity expectation for one or more feature values ; 

(d) comparing the new alert with the one or more existing alert classes ; and either: 
(e1) associating the new alert with a one or the one or more existing alert classes 

that the new alert most closely matches ; or 

(e2) defining a new alert class that is associated with the new alert . (Emphasis 
added) 



28. A system for organizing alerts into alert classes, both the alerts and the alert 
classes having a plurality of features, each of the plurality of features having one or 
more values, the system comprising: 

(a) means for receiving a new alert; 

(b) means for identifying a set of similar features shared bv the new alert and one or 
more existing alert classes ; 

(c) means for updating a similarity expectation for one or more feature values ; 

(d) means for comparing the new alert with the one or more existing alert classes ; 
and 

(e1) means for associating the new alert with a one of the one or more existing alert 
classes that the new alert most closely matches, or defining a new alert class that is 
associated with the new alert . (Emphasis added) 

As discussed above, nowhere does Nine teach or even suggest the desirability 
of classifying of alerts by comparing features of the alerts to features of existing alert 
classes . Moreover, even assuming for the sake of argument that the disclosure of Nine 
can be interpreted as teaching the classification of alerts, Nine fails to teach or suggest 
several other claimed features of the present invention, namely, the steps of updating a 
threshold similarity expectation for one or more features of an alert relative to features 
of alert classes and of updating a similarity expectation for one or more features . The 
Examiner does not appear to have addressed the Applicants' previous arguments with 
respect to these features of the claimed invention. Therefore, the Applicants submit that 
independent claims 1,7, 13, 20, 24, and 28 fully satisfy the requirements of 35 LLS.C. 
§103 and are patentable thereunder. 

Dependent claims 2, 8, 14, 21, 25 and 29 depend from claims 1, 7, 13, 20, 24, 
and 28 and recite additional features therefore. As such, and for at least the same 
reasons set forth above, the Applicants submit that claims 2, 8, 14, 21, 25 and 29 are 
not made obvious by the teachings of Nine. Therefore, the Applicants submit that 
dependent claims 2, 8, 14, 21 , 25 and 29 also fully satisfy the requirements of 35 U.S.C. 
§103 and are patentable thereunder. 
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III. ARGUMENTS MADE IN PREVIOUS RESPONSE 

The Applicants note that the Final Office Action does not address the arguments 
made in Applicants 1 most recent response of May 15 2008 (addressing the rejection 
under 35 U.S.C. §103 over Purtell in view of Timm, made in the Office Action of 
November 15, 2007). As such, and since the Examiner chose instead to rely on Nine in 
making the present rejections, the Applicants assume that the arguments made in the 
response of May 15 2008 were persuasive and that the rejection over Purtell in view of 
Timm has been withdrawn. 

IV- CONCLUSION 

Thus, the Applicants submit that all of the presented claims fully satisfy the 
requirements of 35 U.S.C. §112 and 35 U.S.C. §103. Consequently, the Applicants 
believe that all of these claims are presently in condition for allowance. Accordingly, 
both reconsideration of this application and its swift passage to issue are earnestly 
solicited. 

If, however, the Examiner believes that there are any unresolved issues requiring 
the maintenance of the final action in any of the claims now pending in the application, it 
is requested that the Examiner telephone Kin-Wah Tong, Esq, at (732) 530-9404 so that 
appropriate arrangements can be made for resolving such issues as expeditiously as 
possible. 

Respectfully submitted, 

November 24, 2008 
Date 



Patterson & Sheridan, LLP 
595 Shrewsbury Avenue 
Shrewsbury, New Jersey 07702 
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Kin-Wah Tong, Attorney 
Reg. No. 39,400 
(732) 530-9404 
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